1. Field of the Invention
The present invention relates to a new and improved secure token access distributed database and system for using same, more specifically, the present invention relates to a new and improved secure token access distributed database system to provide verification of someone's or something's identity quickly and securely, wherein such database and system is readily scalable from local to nationwide to worldwide use.
2. Description of the Related Art
There is a pressing continuously present need to provide verification of someone's or something's identity quickly and securely. Routinely such tokens as a driver's license, employee badge, or a credit card are used to verify identity and grant access to privileges. The granter of such privileges is basing access on the validity of the token. These tokens have been shown to be vulnerable to various forms of forgery and attack, including theft. In fact, today over 47% of all fraud involves some sort of identity theft, usually in the form of credit card (or other token) fraud. Once privileges are granted based on a forged or stolen token, those privileges may be used in a detrimental fashion to compromise the system, process, or data accessed.
In addition many situations require immediate access to stored knowledge based on a user identity (ID) and optionally an individual's personal identification number (PIN). This data may provide security information regarding the ID or ID carrier, or it may be information conforming to a query defined by the application, the ID carrier, or both. A credit card or a bank's automatic teller machine (ATM) purchase transaction is one of numerous such circumstances where the data may provide security information regarding any token used for identification.
The relatively new area of data verification in wide area networks requires that a application running on a non-secure computer, for example a personal digital assistant (PDA), gain access to secure data (whether program or informational) while maintaining the security of the acquired data.
The secure data required by these applications may be distributed over many databases maintained and/or owned by varying authorities. MasterCard, Visa, state driver's license, social security, company employee records, and airline boarding database are a few of the databases that a single application may need to post requests for information. In addition each database has fields that the owner is willing to share and others, which are considered confidential. There is no current method to access a wide variety of data from diverse locations securely.
1. Verifiability of the User/user ID                Authenticity of Physical Medium: such as magnetic stripe (e.g., credit cards, ID cards, driver's licenses) or smart chip (also known as smart card) technology. In other words, how do we prove the ID (card, badge, etc.) is the original and not a copy?        Authenticity of the ID carrier/presenter: that is, is the ID carrier the correct, authorized user? If a PIN is used how do we prove the PIN has not been stolen?        
2. Information (data)
Request Type. The request may be of any of several types: e.g., ID verification; additional or updated data regarding the ID or ID carrier; informational based on the requesting application type and/or a user formulated query.
                Availability/Quantity of data depends on several factors. First, the amount of information associated with a given ID or informational query that has actually been stored in one or more storage devices (e.g., databases, files, smart chips, magnetic stripe, and paper). Second, accessibility to those storage devices (e.g., reports, dedicated connectivity, internet, magnetic or chip reader). Third, timeliness in obtaining the data (seconds, minutes, hours or days).        Access and Filtering of obtainable data (as defined above) is based on one or more of the following: 1) the requesting application type; 2) the verified ID, itself; 3) the authorization level of that ID; 4) The authorization level of the entity requesting authentication of the submitted ID (note that the ID of a requesting entity must, itself, be authenticated); and 5) the content and structure of an informational query.        
Scenarios may Include the Following:
1. Customs officer at the border; Security Guard at a secure loading/unloading yard; federal, state or local police patrol officers engaged in a traffic stop—needs to verify the authenticity of a truck driver's license, his identity and his authorization to transport/load/unload a particular cargo.
2. Individual attempting to enter/access a secure area/building/room/data terminal.
3. Individual attempting to purchase goods or services using a credit device (e.g., credit card, debit card, smart chip, smart card)
4. Individual attempting a purchase by providing a credit application and ID (e.g., automobile).
5. Immigration/passport control at entry point to US (and potentially other client countries).
6. Researcher requesting restricted information from a secure database.
Currently Implemented Attempted Solutions
The current solutions to the basic problem are varied, but each is limited in scope.
Little or No Ability to Authenticate ID Media
Generally, a security system, whether it consists of a magnetic reader, a human “gate keeper” or both, either assumes the ID medium is valid, or subjects it to visual verification which is highly inaccurate if the medium is of valid type, but is not the original. (e.g., a false credit card usually contains a valid magnetic stripe visually and compositionally indistinguishable from an original, but carries magnetic data copied from a different card.)
Aside from the issue of insuring that a card or badge is not a fake, there are more general practical reasons for concern. In the case of badge access to areas, buildings, data terminal, etc., generally, a central database contains the encrypted code with access privilege data. When a badge is swiped the magnetic code on it is compared to the database to ensure it is a valid code before entry is granted. The database comparison is necessary because the badge and reader have no internal ability to authenticate the badge/code. Should the database, or the link to it, go down everyone is locked out until the database or link is repaired. If the locks use previously stored data to allow access a potential security hole is created. Either occurrence can be very costly in terms of lost work hours and unauthorized access.
Limited Ability (Easily Vulnerable to Compromise) to Verify Identity of an ID Carrier/presenter by Means Other than the Fact of Possession of the ID Medium.
Often some user input scheme or visual aid is the sole security check or is combined with a magnetic badge or human gatekeeper scheme to add more security “assurance” to a solution. This may consist of a PIN number that, presumably only the true card owner would know; a ZIP code associated with the billing address for the card; numbers printed on card that must be entered at the time of use. If the card/badge is being processed by a person (“gatekeeper”), a picture of the card owner on the card; a “non-reproducible” hologram; or the card owner signature (as examples) may be used, but this presupposes that the card has not been altered. All of these methods can be, and have been, suborned. PIN, ZIP and other numerical information can be observed, stolen or “hacked” from databases. Signatures can be forged. Copied cards can contain pictures of anyone. Non-reproducible holograms can, alas, be reproduced; at least to the extent that they can fool the human eye since general infrastructure does not exist to mechanically verify them.
Limited Insurance of Data Currency (Integrity) for Aid in Security Evaluations.
Current solutions are limited in their ability to address concerns regarding the currency and accuracy of the data available in a centralized database. There may be reasons, known to outside sources, why a given individual, even if his badge is authentic, should not be given access or at least should have access questioned. This poses a significant security risk, but currently, it is usually impractical or impossible to obtain or keep such information available and current for everyone that may seek access to a physical location or to restricted data. Reliance on a central database for current information can severely limit access to knowledge that may prove critical. Also, in many circumstances, the system is not flexible enough to handle a newly issued ID or an ID from an outside location that is, in fact valid, but not yet registered in a local database.
Smart Chip Technology
One of the limitations of current magnetic stripe technology is the relatively limited amount of data (approximately 64,000 bits or 64 Kb) that can be stored. On-card data useful in determining validity is likewise limited. Some current solutions look to smart chip technology. While it is true that significantly more data can be stored on a chip, the data, itself, is not necessarily more secure. As with magnetic stripe technology, PIN access to chip data can be observed or stolen and chips can be copied, and their encryption schemes broken.
In addition, chip technology is significantly more expensive per unit than magnetic stripe, and the infrastructure for chip access is not as ubiquitous and varies by manufacturer. If a chip encryption scheme is defeated, the cost of replacing the access technology (readers and writers) as well as the smart cards is prohibitively high.
Proposed Solutions
The proposed solutions use a combination of technologies to address the issues described in the above sections. These technology combinations depend on a number of factors, but can be application specific.
Card Authentication
The issue of card authentication is primarily addressed using Semtek Innovative Solutions, Inc. proprietary Secure Stripe™ (SS) technology covered in U.S. Pat. Nos. 5,770,846 and 6,260,146 (as well as pending U.S. patent applications Ser. Nos. 09/901,846 and 09/901,920 which have since been published as U.S. Patent Publication Nos. US 2002-0017559 A1 and US 2002-0017560 A1, respectfully). U.S. Pat. Nos. 5,770,846 and 6,260,146 (as well as pending U.S. patent applications Ser. Nos. 09/901,846 and 09/901,920) provide a means for establishing if a card is the original repository of a particular magnetic stripe data stream/segment, or is a copy. It does this by reading the “magnetic signature” of the magnetic media on the original card and encrypting it using a key or combination of keys that may be tied to the original writer and/or a PIN. This encrypted signature data is then added to the main data, which is also encrypted, and written to the stripe on the card. When the card is swiped in an SS reader, the magnetic signature of the current media is recorded. The stored signature in the magnetic stripe data stream/segment is decoded either using a public key known to the SS reader, a PIN entered by the card carrier, a PIN entered by a human monitor (e.g., sales clerk or security guard), or a combination, and is then compared to the current media signature just read. If signatures do not match, or keys fail decryption, the card is rejected and/or access is denied.
In another version rather than using a PIN number, which is prone to be forgotten, observed, or hacked (due to its limited range of values). A number of personal questions are asked when the card is first enabled. These questions are designed to be easily remembered by the user and not recorded or generally known. Examples of such questions may be: Do you like dogs? Do you like tattoos? The answers are used to generate a digital key and then discarded. During the verification process a random selection of one or more questions are asked. The answers are entered on a secure device such as a PIN pad, Secure Swipe PDA, or secure computer keyboard. The secure input device is required to prevent a computer virus or keyboard “sniffer” from recording the PIN question answers for later use by an intruder. Since the accessed data bases contain only the key generated by the answers and not the answers a breach of security of a database does not compromise the system.
Since this authentication occurs using only the card and the reader, a significant level of security assurance (proof of original card) occurs even if verification databases are part of the system but are unavailable for some reason, and access may be granted on that basis. In the unlikely event that an original SS card writer is stolen, and its encryption key is discovered, and it is then used to forge a copy of a badge with its own, now internally consistent signature, the signature of the original card stored in a database at the time it was originally written, can be available for cross-checking. This adds an additional level of security that would require not only the theft of an SS reader and its multiple keys, but the coincidence of database unavailability, to be defeated.
An alternative implementation reads the magnetic signature of the magnetic media and stores the signature along with other encryption data in a remote database. The database can be queried for the signature data when required. This system has a drawback in that it requires having access to the remote database for authentication. The benefit with this method is that a card signature can be created remotely without the requirement of magnetic stripe encoding. This system could generate a signature the first time a credit card or other token is used and store that data using cards currently in distribution. This system would be used until the normal issuance of new secure cards will replace cards in use.
Smart Chip Technology
In the case of Smart Chip technology, U.S. Pat. No. 6,260,146 (as well as pending U.S. patent applications Ser. Nos. 09/901,846 and 09/901,920) provides for additional self-referencing between the magnetic stripe data (encompassing the security protections just described) and data stored and similarly encrypted on the chip. Although individual chip signatures are problematic and more difficult and costly to establish, the SS magnetic stripe technology can provide that safeguard at minimal cost and be cross-checked against data encrypted on the chip.